home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11413 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB
  1. Path: solon.com!not-for-mail
  2. From: seebs@solutions.solon.com (Peter Seebach)
  3. Newsgroups: comp.lang.c++,comp.lang.eiffel,comp.lang.c,comp.object,comp.software-eng
  4. Subject: Re: Beware of "C" Hackers -- A rebuttal to Bertrand Meyer
  5. Date: 14 Mar 1996 08:13:35 -0600
  6. Organization: Usenet Fact Police (Undercover)
  7. Message-ID: <4i99if$8ve@solutions.solon.com>
  8. References: <1995Jul3.034108.4193@rcmcon.com> <314628F2.31C8@aud.alcatel.com> <RMARTIN.96Mar13110714@rcm.oma.com> <4i862r$1evq@saba.info.ucla.edu>
  9. NNTP-Posting-Host: solutions.solon.com
  10.  
  11. In article <4i862r$1evq@saba.info.ucla.edu>,
  12. Jay Martin <jmartin@cs.ucla.edu> wrote:
  13. >No "hacking" is broader than that, it is writing poor code period.
  14.  
  15. Bullshit.  Read the jargon file.
  16.  
  17. >It is writing low level or obscure code when it is unnecessary because
  18. >you think that its great.
  19.  
  20. No.
  21.  
  22. >Note that when I use the term "Software Engineering", I am talking
  23. >about optimizing the design and implementation of software which means
  24. >using the best tools and techniques.
  25.  
  26. Oh, I see.  You mean hacking, except that you're only allowed to use
  27. preexisting tools, not invent new ones.
  28.  
  29. >Competent software engineers
  30. >are not hackers.  Hackers do not like the restrictiveness of an
  31. >Eiffel or an Ada or any other software engineering language, thus
  32. >these languages are not likely to attract hackers.  C is
  33. >unrestrictive and attracts hackers in droves.
  34.  
  35. Hackers object to stupid restrictions, but are not as dumb as you seem to
  36. think.  I think the word you're looking for is "hacks".  "hack programmers"
  37. are an entirely different species.
  38.  
  39. >I have never worked
  40. >with an Eiffel programmer, but given an Eiffel programmer spouting
  41. >high level design and implementation concepts and a C programmer who
  42. >says "I use pointer arithmetic cuz it may be faster, I don't trust no
  43. >compilers" and "I write terse code all on my line cuz its cool like
  44. >mathematics and gee, I is a mathematical genius or something",
  45. >the Eiffel programmer is basically going to get the job. 
  46.  
  47. And for good reason.  The key point is that, if the C programmer were the
  48. one talking about design concepts, and the Eiffel programmer were talking
  49. about cool optimizations she learned for the implementation she used, you'd
  50. hire the C programmer.
  51.  
  52. >In my book, to be a competent software engineer you must must also be
  53. >an very knowledgable at computer language design and also compiler 
  54. >optimization.  Its common knowledge that C is poorly designed and
  55. >thus rabid worshipers of C are not too swift.
  56.  
  57. Not poorly designed, just designed for different goals and a different
  58. environment than you're working in.
  59.  
  60. >If C is so wonderful for making high level code, then what the bleep
  61. >was C++ invented for?
  62.  
  63. OO, and to be more like Simula.
  64.  
  65. >Most code written in C is low level crap. Is
  66. >it "easier" in C to write high level code than other "high level"
  67. >languages?
  68.  
  69. That first statement is amusingly stupid.  No, it's not easier.  It's also
  70. not notably *harder*.  It requires a different kind of discipline, but it's
  71. the same basic thing - a good high level programmer will write elegant and
  72. maintainable assembler code.
  73.  
  74. >I don't have problems with high level C programmers who
  75. >understand the limitations of their tools.  I don't see "rabid C
  76. >fanatics" who mostly worship the low level in this catagory.
  77.  
  78. Well, here's a rabid C fanatic who loathes low-level code, and considers it
  79. an abomination to assume that int has a multiple of 8 bits.
  80.  
  81. >To demonstrate the "C hacker culture" (filed under macho attitudes)
  82. >here's a random recent example:
  83.  
  84. >rmartin@oma.com (Robert C. Martin) writes:
  85. >>No, I disagree with your point.  It is not the responsibility of the
  86. >>language to make the engineer better.  It is the responsibility of the
  87. >>engineer to become adept at the language.
  88.  
  89. >Clear demonstration of views that have left software engineering
  90. >and entered the "C Hacker Zone".
  91.  
  92. No, it's a philosophical distinction.  I agree with him; it is *impossible*
  93. to make someone think in high level terms.  A bad programmer will make
  94. design and stylistic errors in Ada, too.  Languages can prevent typos, and
  95. low-level errors.  They cannot prevent stupid design.  (Unless Ada can
  96. detect bubblesort, and optimize it into something better?)
  97.  
  98. Anyway, go read the jargon file.  Your penance for abusing the word "hacker"
  99. is to go three days without using any technology based on work done by real
  100. hackers.  You are forbidden from using compilers, editors, and digital
  101. computers for three days.  Say 100 "hail Knuth"'s, and write "I will not
  102. overgeneralize against the Great Makers" 500 times on your most expensive
  103. letterhead.
  104.  
  105. -s
  106. -- 
  107. Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
  108. C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
  109. FUCK the communications decency act.  Goddamned government.  [literally.]
  110. The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html
  111.